1. Field of the Invention
The invention relates to systems and methods for debugging software in real time. More particularly, the invention relates to systems and methods for the real time debugging of firmware in embedded systems, e.g. ASIC chips having one or more processors on a single chip.
2. State of the Art
Software debugging may be accomplished in a number of ways, some of which are not performed in real time. A traditional debugging technique is to step through program instructions at a rate much slower than the rate at which the program is designed to run in real time. By stepping through the program instructions one-by-one, errors can be observed as they happen and the program code lines executed immediately prior to the error can be analyzed to find the cause of the error. This technique is not helpful, however, if the error in program execution is the result of timing errors or other types of errors which only occur when the program is running at real time speed. As used herein, the term "real time" means the rate at which a program must execute in order to process the incoming data rate which may be quite high.
A widely used technique for debugging a program which is running in real time is called "tracing". Tracing involves recording the transactions performed by the computer as it executes the program code. The trace of activities performed by the computer during the time of a failure can be a useful guide in isolating possible causes of the failure.
Another useful debugging tool is to set breakpoints at selected places in the program. The breakpoints trap the flow of the software and provide insight into whether, when, and how certain portions of the software are entered and exited. An analysis of the flow of the software can provide information which is useful in isolating bugs.
Many state-of-the-art tracing and trapping methods are accomplished by a debug support circuit which is connected to the system bus, i.e. the bus which couples the CPU to memory. See, for example, U.S. Pat. No. 5,491,793 to Somasundaram et al. entitled "Debug Support in a Processor Chip." Connecting a debug circuit to the system bus is convenient because addresses, instructions, and data can be accessed via the system bus. However, coupling the debug support circuit to the system bus increases the electrical load on the bus and interferes with the operation of the bus. Moreover, operation of the system bus may interfere with operation of the debug support circuit. In addition, the system bus may not provide all the information necessary for debugging a program running on a CPU which uses internal cache. These CPUs will not access the system bus if the information they need is available in cache. If an error occurs while the CPU is accessing internal cache, the debug support circuit will not be able to access the information it needs.
Another tracing and trapping method is disclosed in U.S. Pat. No. 5,833,310 to Whistel et al. entitled "On-Chip In-Circuit-Emulator Memory Mapping and Breakpoint Register Modules." According to this method, an internal bus controller is coupled to the memory address bus and a match register. When a memory address written to the address bus matches an address in the match register, a memory mapping module maps a memory cycle to an external debug memory. The user can set specific bus event conditions for which memory is mapped by writing to a set of breakpoint registers. A disadvantage of this method is that it requires an additional set of I/O pins for the chip so that the external debug memory can be coupled to the chip. This may require a significant number of pins since the addresses to be mapped may be 32 or 64 bits wide.
Still another tracing and trapping method is disclosed in U.S. Pat. No. 5,513,346 to Satagopan et al. entitled "Error Condition Detector for Handling Interrupt in Integrated Circuits Having Multiple Processors." According to this method, an interrupt processor controller intercepts all interrupts and routes them to the appropriate processor in a multiprocessor chip. The interrupt processor controller includes logic which determines when an interrupt will cause an error because a previously instigated interrupt has not been cleared. When such an error is detected, a bit is set in an error detect register, the bit corresponding to an interprocessor interrupt channel. The bits in the register are ORed and a single bit output indicates the occurrence of an error. The register may then be examined to determine the location of the interrupt error in the executing code. This method does not interfere with the system bus and does not require very many additional pins on the chip. However, the debugging information that it provides is limited.
The Motorola MPC-860 PowerQuicc.TM. includes a program development system interface port which provides a three bit output indicative of the state of the program execution as the program is being executed. The MPC-860 is a 40 mHz communications controller but the development system interface port is only operable at a rate of 4 mHz. Thus, the port can not be used for real time debugging. The specifications for the MPC-860 are found in the "MPC-860 POWERQUICC USER'S MANUAL", Copyright 1996 Motorola, Inc., Schaumberg, Ill., the complete disclosure of which is incorporated herein by reference.
ASIC design using one or more embedded processors poses additional debugging challenges. The prior art methods of trapping instructions at a given point in time implies that the system must be stopped to allow debugging of firmware. Once the system is stopped, however, real time events and their timing relationships are lost. If there is a firmware bug which is only identifiable in the presence of live traffic (during real time operations) it is necessary to obtain contextual information about the error before the firmware is changed.